「為什麼要 Code Review」以及「 Code Review 有什麼好處」，我想前人都已經講的很多了，我今天就不多贅述，先聊點別的吧。

倘若團隊沒有 Code Review 的文化，那我進團隊後第一個推廣的團隊文化通常就是 Code Review。但這通常不是一件簡單的事情，通常在推行時都會遇到不少阻礙。

以在學生時期約幾個人進行同一個專案的狀況為例，老師通常不會關注你們怎麼進行團隊的開發，而只看你們是否要在時間內把成果完成，這就面臨了沒有高階主管能夠協助倡導的助力了。彼此標準不同、風格不同、習慣不同，這時候誰不一定服誰，憑什麼就一定要聽某個人的，為什麼一定要進行 Code Reveiw，反正老師說要做的需求我已經完成，直接推上去就好，幹嘛那麼麻煩。最後這件事很容易就在有人不配合的情況下不了了之。

但在職場時，Code Review 這種事難道會隨著彼此尊重、更加理性而好推廣嗎？不，這時候可能會遇到更多問題，比如說 Code Review 的標準是什麼？我該找誰幫忙 Code Review？若是找的那個人沒空該怎麼辦，難道成果一直卡在那邊有比較好嗎？我覺得我這樣寫是好的，但是 Reviewer 卻說不行，彼此不服誰，又再度卡住甚至吵起來又該如何是好？種種顧慮會在推廣時被提出，若是沒辦法取得共識，就難以繼續推行下去。

前者的案例，礙於我當時沒能說服，最後是放棄對前輩、同輩的推廣這項政策，但是卻從後輩開始推廣，並以身作則，帶他們一起互相檢視彼此的程式碼。後者的案例，則在彼此充分討論過後，得到一個最低 Code Review 通過標準，開始落實。當然這之後也是會遇到一些障礙等待討論與解決，但也給了我們許多新的見解和經驗，我今天所分享的就是這一部分。

上一段提到了「最低 Code Review 通過標準」，我想就是一個重點，這也是在前面有提過的顧慮之一。在討論的最後，團隊得出一個最低標準就是以「Reviewer 能看懂變動的程式碼」為主，為什麼會這樣訂定呢？這就與我們認為 Code Review 的主要目的有關了。

通常維護軟體專案最怕的是，該段程式碼在編寫者不在時出了問題，卻沒人能夠幫忙處理。所以團隊認為 Code Review 目前最有價值得部分應該是分散維護風險，因為透過 Code Review，一份程式碼至少有兩個人熟悉，如果主要負責人在忙或是請假時，至少有另一個人可以幫忙處理。這也包括若是同事因生涯規劃而離職後，不會讓該專案變成無人敢踏足的危樓，生怕改動後就會導致專案崩潰。這也同時降低了在請假前或離職前，交接者與承接者的瞬間負擔。

基於這個目的，對最低標準做了點補充。什麼叫做看懂？就是 Reviewer 能夠向編寫者以外的第三人解釋這份變動，以及在該專案遇到問題時，能知道錯誤有沒有可能是出自這份變動，並在遇到問題時或需求時能夠更改相關程式碼。

至於，程式碼風格、演算法效率、是否能正確建置等問題，都是次要的，且能通過自動化去檢核的，不該在每次 Code Reivew 時去仰賴人工檢核。而且在團隊沒有統一風格標準前，這類的問題加進來都只會增加導入這個政策的成本。不是說不做，而是不再剛導入時就這麼做。

而且 Reviewer 以要看懂時為目的時，就會在不懂時不斷提問：當編寫者寫太醜導致看不懂被提問時，就會嘗試更改風格。當邏輯與變動目的不相符被提問時，就會修正錯誤。這些都能保證程式碼在合併前，至少都有最基本的品質了。

其他問題是可以被建議，都不被要求強制執行的。像是可能會有更好的作法，但是至少現在的也能通過，若一直追求極致，可能會有過度設計或是導致這份變動在不斷更改的要求下超過原本預計的時程。所以在實作上都先以編寫者為主，畢竟他是最直接相關者，其他檢視者並沒有真的跳下去實作，雖然會有好的建議，但有時候卻也會發生只出一張嘴，但實際細節卻沒考慮進去的情況。

Code Review 細節標準，是可以在之後團隊取得共識後，逐步要求的。在初期 Code Review 的重點也應該先著重在溝通解決事情，去聚焦在在功能的完整性與日後的維護性，而不是有如雞蛋裡挑骨頭的去逐字檢視對方的文法似的評論程式碼的風格。

講到這邊做個收尾。今天分享的是如何導入 Code Review，而 Code Review 的標準常常是在想要落實遇到的最大阻礙，其他細節多是可以日後遇到問題時，團隊再聚在一起討論凝聚共識的。所以透過聚焦論述這部分，提供點經驗與見解，希望以「Reviewer 能看懂變動的程式碼」為最低標準的這種方式，能有助於大家去導入。若有其他導入的經驗，也歡迎在下方留言，彼此交流囉。 = )